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Abstract 
This document updates RFC 5761 by clarifying the SDP offer/answer 
negotiation of RTP and RTP Control Protocol (RTCP) multiplexing. It 
makes it clear that an answerer can only include an "a=rtcp-mux" 


attribute in a Session Description Protocol (SDP) answer if the 
associated SDP offer contained the attribute. 


Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 7841. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc8035. 
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1. Introduction 
RFC 5761 [RFC5761] specifies how to multiplex RTP data packets and 
RTP Control Protocol (RTCP) packets on a single UDP port, and how to 
negotiate usage of such multiplexing using the SDP offer/answer 
mechanism [RFC3264] with an "a=rtcp-mux" attribute. However, the 
text is unclear on whether an answerer is allowed to include the 
attribute in an answer even if the associated offer did not contain 
an attribute. 
This document updates RFC 5761 [RFC5761] by clarifying that an 
answerer can only include an "a=rtcp-mux" attribute in an answer if 
the associated offer contained the attribute. It also clarifies that 
the negotiation of RTP and RTCP multiplexing is for usage in both 
directions. 
2. Conventions 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


3. Update to RFC 5761 


This section updates Section 5.1.1 of RFC 5761 by clarifying that an 
answerer can only include an "a=rtcp-mux" attribute in an answer if 
the associated offer contained the attribute, and by clarifying that 
the negotiation of RTP and RTCP multiplexing is for usage in both 
directions. 
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3.1. Update to Section 5.1.1 


In this section, any references to Sections 4 and 8 are to those 
sections in [RFC5761]. 


OLD TEXT: 


When the Session Description Protocol (SDP) [8] is used to negotiate 
RTP sessions following the offer/answer model [9], the "a=rtcp-mux" 
attribute (see Section 8) indicates the desire to multiplex RTP and 
RTCP onto a single port. The initial SDP offer MUST include this 
attribute at the media level to request multiplexing of RTP and RTCP 


on a single port. For example: 
v=0 
o=csp 1153134164 1153134164 IN IP6 2001:DB8::211:24ff:fea3:7a2e 
s=- 


c=IN IP6 2001:DB8::211:24ff:fea3:7a2e 
t=1153134164 1153137764 

m=audio 49170 RTP/AVP 97 

a=rtpmap:97 iLBC/8000 

a=rtcp-mux 


This offer denotes a unicast voice-over-IP session using the RTP/AVP 
profile with iLBC coding. The answerer is requested to send both RTP 
and RTCP to port 49170 on IPv6 address 2001:DB8::211:24ff:fea3:7a2e. 


If the answerer wishes to multiplex RTP and RTCP onto a single port, 
it MUST include a media-level "a=rtcp-mux" attribute in the answer. 
The RTP payload types used in the answer MUST conform to the rules in 
Section 4. 


If the answer does not contain an "a=rtcp-mux" attribute, the offerer 
MUST NOT multiplex RTP and RTCP packets on a single port. Instead, 
it should send and receive RTCP on a port allocated according to the 
usual port-selection rules (either the port pair, or a signalled port 


if the "a=rtcp:" attribute [10] is also included). This will occur 
when talking to a peer that does not understand the "a=rtcp-mux" 
attribute. 


When SDP is used in a declarative manner, the presence of an 
"a=rtcp-mux" attribute signals that the sender will multiplex RTP and 
RTCP on the same port. The receiver MUST be prepared to receive RTCP 
packets on the RTP port, and any resource reservation needs to be 
made including the RTCP bandwidth. 
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NEW TEXT: 


When the Session Description Protocol (SDP) [8] is used to negotiate 
RTP sessions following the offer/answer model [9], the "a=rtcp-mux" 

attribute (see Section 8) indicates the desire to multiplex RTP and 

RTCP onto a single port, and the usage is always negotiated for both 
directions. 


If the offerer wishes to multiplex RTP and RTCP onto a single port, 
the initial SDP offer MUST include the attribute at the media level 
to request multiplexing of RTP and RTCP on a single port. For 
example: 


v=0 

o=csp 1153134164 1153134164 IN IP6 2001:DB8::211:24ff:fea3:7a2e 
55> 

c=IN IP6 2001:DB8::211:24ff:fea3:7a2e 

t=1153134164 1153137764 

m=audio 49170 RTP/AVP 97 

a=rtpmap:97 iLBC/8000 

a=rtcp-mux 


This offer denotes a unicast voice-over-IP session using the RTP/AVP 
profile with Internet Low Bit Rate Codec (iLBC) coding. The answerer 
is requested to send both RTP and RTCP to port 49170 on IPv6 address 
2001:DB8::211:24ff:fea3:7a2e. 


If the offer contains the "a=rtcp-mux" attribute, and if the answerer 
wishes to multiplex RTP and RTCP onto a single port, it MUST include 
a media-level "a=rtcp-mux" attribute in the answer. The RTP payload 
types used in the answer MUST conform to the rules in Section 4. If 
the offer does not contain the "a=rtcp-mux" attribute, the answerer 
MUST NOT include an "a=rtcp-mux" attribute in the answer, and the 
answerer MUST NOT multiplex RTP and RTCP packets on a single port. 


If the answer contains an "a=rtcp-mux" attribute, the offerer and 
answerer MUST multiplex RTP and RTCP packets on a single port. 


If the answer does not contain an "a=rtcp-mux" attribute, the offerer 
and answerer MUST NOT multiplex RTP and RTCP packets on a single 
port. Instead, they should send and receive RTCP on a port allocated 
according to the usual port-selection rules (either the port pair, or 
a signalled port if the "a=rtcp:" attribute [10] is also included). 
This will occur when talking to a peer that does not understand the 
"a=rtcp-mux" attribute. 
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When SDP is used in a declarative manner, the presence of an "a=rtcp- 
mux" attribute signals that the sender will multiplex RTP and RTCP on 
the same port. The receiver MUST be prepared to receive RTCP packets 
on the RTP port, and any resource reservation needs to be made 
including the RTCP bandwidth. 


4. Security Considerations 


The security considerations for RTP and RTCP multiplexing are 
described in RFC 5761. This specification does not impact those 
security considerations. 


5. IANA Considerations 


IANA has added a reference to this document for the att-field (media 
level only) registration "rtcp-mux" in the "Session Description 
Protocol (SDP) Parameters" registry. 
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